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REMARKS 

This is a full and timely response to the final Office Action mailed July 21, 2009. 
Reconsideration and allowance of the application and presently pending claims are respectfully 
requested. 

Present Status of Patent Application 

Claims 2-4, 7-12, 14, 16, 18-21, 23, 25-33, and 36-38 are pending in the present 
application. Specifically, claims 11, 19, 25-27, 29-31, and 33 have been currently amended 
without adding new matter; claims 2-4, 7-12, 14, 16, 18, 20, 21, 23, 28, 32, and 36 are previously 
presented; claims 1, 5, 6, 13, 15, 17, 22, 24, 34, and 35 have been canceled without prejudice, 
waiver, or disclaimer; and claims 37 and 38 are new claims submitted without introduction of 
new matter. Reconsideration and allowance of the application and presently pending claims are 
respectfully requested. 

Applicants' Response to Statements in pages 2-4 of the Office action 

Applicants respectfully traverse several remarks made in pages 2-5 of the Office action in 
response to Applicants' earlier arguments. 

Specifically, in page 2, it is pointed out that: "Applicant argues that the referenced prior 
art, does not disclose, a two step process for attestation; two pre-attestation messages. " This is 
followed by a rebuttal of Applicants' remark. The rebuttal states: "Yan prior art discloses for 
claims 31, 18, 19, 30, 31, two message flows used for the initiation and completion of attestation 
between two entities. The two message-flows (paragraph [0064], lines 1-4; paragraph [0064], 
lines 8-10) initiate attestation and establish the requirements for the attestation information 
transferred between the entities," and then goes on to assert: "The can-attest and attestation- 
wanted (request, response) messages are used as an attestation initiation protocol sequence. The 
Yan prior art discloses the initiation of a trust relation between two entities or the initiation of 
attestation using a two step process as discloses above." 
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Applicants acknowledge that Yan does indeed disclose two message flows (paragraph 
[0064] and Fig. 3) in the form of 1) a first message flow (challenge 302 — response 304) and 2) a 
second message flow (certificate/conditions 306 - confirmation 308). However, Applicants 
respectfully assert that neither one of Yan's two message flows reasonably teach or suggest 
Applicants' ("can-attest" - "attestation- wanted") message flow. 

A blanket allegation (page 3 of the Office action) that "The Yan prior art discloses the 
initiation of a trust relation between two entities or the initiation of attestation using a two step 
process as discloses (sic) above" fails to adequately address various aspects of Applicants' 
claims that are clearly distinct and different than Yan. 

Provided below is a non-comprehensive list of reasons for Applicants' assertion: 

1) the Office action fails to unambiguously disclose which specific messages of Yan 
are considered to correspond to Applicants' messages (Docs Yan's "challenge 302" 
corresponds to Applicants' "can-attest"??) 

2) the direction of message flows do not match (Yan's message pair flows are in 
opposite directions to Applicants' message pair flows) 

a) Yan's "challenge" message flows from trustor to trustee, while Applicants' 
"can-attest" message flows in the opposite direction from trustee to trustor 
(seeking trustor's trust). 

b) Yan's "response" message flows from trustee to trustor while Applicants' 
"attestation-wanted" message flows in the opposite direction (providing details 
for obtaining trustor's trust) 

3) the contents of the messages do not match (Applicants' "can-attest" message 
includes a query seeking to know whether an attestation message is required and if so, 
what are the requirements. In contrast, Yan's "challenge" message is described in his 
paragraph [0061] as follows: "a challenge, e.g., 222, to the buyer/supplier platform to 
determine that it is a trusted system"). 

Additional remarks in the items listed above, as well as in other matters are provided 

below. 
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Claim Rejections under 35 U.S.C. $103 
I. Statement of the Rejection 

Claims 2-4, 7-12, 14, 18-21, 23, 25-27, 29, 31 (and 32-36) are rejected under 35 U.S.C. 
103(a) as being unpatentable over Yan et al. (US PGPUB No. 20050033987) in view of Qui (US 
PGPUBNo. 20040148505). 

Response to the Rejection 

Independent claim 31 

Applicants respectfully traverse the rejection of this claim for several reasons. 
Nonetheless, Applicants have opted to amend claim 31 in an effort to move forward prosecution 
in the case. As amended the claim now includes: "verifying the validity of the code ID in the 
second computer entity, the verifying comprising determining that the first computer entity is not 
included in a do-not-trust list ." Applicants respectfully submit that the claim is allowable over 
the cited references of Yan and/or Qui that fail to reasonably teach or suggest a do-not-trust list . 

Claim 31 is further allowable because the cited reference of Yan fails to disclose or 
suggest an attestation message and a trust message as improperly alleged in the rejection. 

In this context, the Office action alleges that Applicants' attestation message is disclosed 
in "Yan paragraph [0064], lines 1-17: initial attestation transmitted via message flow between 
trustor and trustee to establish trust relationship; Yan discloses a two step process for attestation 
messages (message flows 302, 304 and message flows 306, 308))." However, Applicants 
respectfully submit that this citation is improper for at least the following reasons: 

1) the citation is ambiguous in that it fails to identify which specific one of Yan' s 
messages (302, 304, 306 or 308) teaches Applicants' attestation message 

2) where in Yan can be found a code ID element as recited in this portion of the claim 

3) where in Yan can be found a security ID element as recited in this portion of the claim 
The Office action further alleges that Applicants' trust message is disclosed in "Yan 

paragraph [0060], lines 6-53: verify signature, attestation information; paragraph [0062], lines 
1-41 paragraph [0064], lines "14: session key exchanged between entities for future messaging, 
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communications)." Applicants respectfully submit that this citation is also improper for at least 
the following reasons: 

1) the citation is ambiguous in that it fails to identify which specific one of Yan's 
messages (302, 304, 306 or 308) teaches Applicants' trust message 

2) the rejection is ambiguous in that it fails to identify which portion of paragraph [0060] 
or [0064] teaches a code ID (signature? attestation information? or session key?) 

3) where in Yan can be found a trust message that is generated after checking validity of 
a code ID 

In view of the reasons listed above, Applicants respectfully re-iterate remarks submitted 
in their earlier response dated 24 March 2009, wherein it was pointed out that the lack of clarity 
in a rejection denies Applicants a fair opportunity to provide evidence of patentability. 

Applicants also re-iterate remarks provided earlier pertaining to Applicants' security ID 
and code ID (under the section titled "Remarks pertaining to new claims 31-36" of the earlier 
response) because the current Office action fails to acknowledge the validity of these remarks or 
else provide a detailed rebuttal. 

In summary, Applicants respectfully submit that the current rejection of claim 31 is 
inadequate and improper and hereby request withdrawal of the rejection followed by allowance 
of the claim. 

Claims 2-4, 7-12, 14, 18, 32, 33 and 36 

Claims 2-4, 7-12, 14, 18, 32, 33 and 36 are directly or indirectly dependent on claim 31, 
which is allowable for reasons provided above. Consequently, claims 2-4, 7-12, 14, 18, 32, 33 
and 36 are also allowable by law arising from claim dependency from an allowable claim. For at 
least this reason, Applicants hereby request withdrawal of the rejection followed by allowance of 
these claims. 

Claims 34 and 35 

Applicants have opted to cancel claims 34 and 35 and respectfully submit that the 
rejection of these claims has been rendered moot as a result of the cancellation. 
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II. Statement of the Rej ection 

Claims 16, 28 are rejected under 35 U.S.C. 103(a) as being unpatentable over Yan in 
view ofGrawrock (US PGPUB No. 20040117625). 
Response to the Rejection 
Claims 16 and 28 

Applicants respectfully submit that claims 16 and 28 are at least allowable by law arising 
from dependency on allowable claims 3 1 and 30 respectively. Consequently, for at least this 
reason, Applicants respectfully request withdrawal of the rejection under 35 U.S.C. 103(a) 
followed by allowance of claims 16 and 28. 

Claim Rejections under 35 U.S.C. §102 
Statement of the Rejection 

Claim 30 is rejected under 35 U.S.C. 102(e) as being anticipated by Yan et al. (US 
PGPUB No. 20050033987). 

Response to the Rejection 
Independent claim 30 

Applicants respectfully traverse the rejection of this claim for several reasons. 

To elaborate upon the first reason, the recitation in page 20 of the Office action includes 
several portions of the claim that have been cancelled in Applicants' previous response and are 
no longer a part of the claim (i.e., "constructing the attestation message", and "the first computer 
entity thereafter sending the attestation message in accordance with the requirements stated in 
the attestation-wanted message.'") 

Elaborating upon a second reason for Applicants' traversal, attention is drawn to the 
following rationale that has been provided for rejecting the claim: "(see Yan paragraph [0064], 
lines G-7: initial attestation transmitted via message flow between trustor and trustee to 
establish trust relationship; Yan discloses a two step process for attestation messages (message 
flows 302.304 and message flaws 306,308))." 



Page 14 of 19 



DOCKET NO.: MSFT-2795 (305124.1) 
Application No.: 10/734,028 
Office Action Dated: July 21, 2009 



PATENT 



In response thereto, Applicants draw attention to remarks provided above under the title 
"Applicants ' Response to Statements in pages 2-4 of the Office action." To reiterate these 
remarks: 

1) the Office action fails to unambiguously disclose which specific messages of Yan are 
considered to correspond to Applicants' messages 

2) the direction of message flows do not match (Yan's message pair flows are in opposite 
directions to Applicants' message pair flows) 

a) Yan's "challenge" message flows from trustor to trustee, while Applicants' 
"can-attest" message flows in the opposite direction from trustee to trustor 
(seeking trustor's trust). 

b) Yan's "response" message flows from trustee to trustor while Applicants' 
"attestation-wanted" message flows in the opposite direction (providing details 
for obtaining trustor's trust) 

3 ) the contents of the messages do not match 

With respect to item 1) above, Applicants respectfully re-iterate remarks provided in their 
previous response dated 24 March 2009. A portion of these remarks is reproduced below for easy 
reference: 

As is known, a proper rejection under 35 U.S.C 102 necessitates that the cited prior art 
reference must teach every aspect of the claimed invention with no question of 
obviousness being present . Applicants respectfully submit that the current rejection of 
claim 30 under 35 U.S.C 102 fails to satisfy this requirement because the cited prior art of 
Yan fails to unambiguously disclose each aspect of the claim. 

Specifically, with reference to claim 30, attention is drawn to page 21 of the 
Office action wherein the claim has been rejected based on "Yan paragraph [0065], lines 
9-15: attestation information (wanted-message) formatted in a negotiated format." 
However, contrary to requirements under 35 U.S.C. 102, no details have been provided as 
to how Yan's lines 9-15 actually disclose anticipatory elements corresponding to 
Applicants' claim elements (e.g., "a can-attest message" and "an attestation-wanted 
message" sent in response thereof). 

Applicants respectfully submit that such an omnibus allegation fails to satisfy 
pertinent guidelines provided in MPEP 706 "Rejections of Claims [R-5]," which state: 
"The goal of examination is to clearly articulate any rejection early in the prosecution 
process so that the applicant has the opportunity to provide evidence of patentability and 
otherwise reply completely at the earliest opportunity." 
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Turning now to item 2) above, Applicants have opted to amend the claim in order to 
clarify that the can-attest message is transmitted by a first computer entity (a client device, 
"trustee") to a server ("trustor"). This is in contrast to Yan's "challenge 302" which is sent in the 
opposite direction from server ("trustor") to user computer ("trustee"). 

Amended claim 30 further clarifies that the attestation-wanted message is transmitted by 
the server ("trustor") to the first computer entity ("trustee") "in response to the can-attest 
message." This is in contrast to Yan's "response 304" which is sent in the opposite direction 
from user computer ("trustee") to server ("trustor"). 

It may be also pertinent to point out that the phrase "in response to the can-attest 
message" as cited in the claim, clarifies that the "attestation-wanted message" follows the "can- 
attest message." Consequently, a proper rejection of the claim will require that the prior art 
disclose this specific sequence of actions. Or, in other words, it would be improper to randomly 
select one of Yan's four messages (302, 304, 306 or 308 of Fig. 3) without indicating how this 
selected message relates to a corresponding inquiry/response message. 

In this context, Applicants respectfully re-iterate remarks provided in their previous 
response dated 24 March 2009. A portion of these remarks is reproduced below for easy 
reference: 

In contrast to Yan's paragraph [0065], Applicants' claim 30 recites a can-attest 
message that is voluntarily sent ( prior to any attestation that may occur subsequently) 
from a second computer entity (e.g. a client) to a first computer entity (e.g. a server) 
enquiring if attestation is required and if so, what are the requirements for an attestation 
message. 

In response to this voluntary "can-attest" message, the first computer entity 
returns an "attestation-wanted" message that outlines the requirements for the attestation 
message. Yan fails to disclose these two pre-attestation messages. 

It may be further pertinent to draw attention to Yan's paragraph [0060] which 
discloses the establishment of trust in a challenge-response format ("it sends the integrity 
metrics, e.g., certificate chain (Chw, Ca), to the remote server as part of the response to 
the challenge depicted in path 222 ") (Emphasis added). Applicants' attestation process 
(recited in claim 19) is carried out subsequent to Applicants' pre-attestation information 
exchange cited in claim 30 (voluntary " enquiry-provide info " format versus Yan's 
" challenge-response " format). 
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To summarize: 

1) Yan's message 314 of paragraph [0065] does not anticipate Applicants' "can-attest" and 
"attestation-wanted" messages. (Moreso, Yan's single message does not reasonably 
anticipate Applicants' two messages - improper for a rejection under 35 U.S.C. 102), 

2) Yan does not teach Applicants' enquiry message "can-attest" message (^'stating that the 
first computer entity can send an attestation message but that the first computer entity 
would like to know from the second computer entity whether such an attestation messase 
is required by such second computer entity and if so any requirements that such second 
computer entity has with regard to such attestation message .") 

3) Yan's "challenge message" (assuming arguendo that such a challenge message is 
interpreted as a "can-attest" message) originates in a server device while Applicants' 
"can-attest" enquiry message originates in a client device. 

In view of the remarks provided above, Applicants respectfully submit that the current 
rejection of claim 30 under 35 U.S.C. 102 is improper and hereby request withdrawal of the 
rejection followed by allowance of the claim. 



Remarks pertaining to new claims 37 and 38 

Applicants respectfully submit that new claims 37 and 38 are allowable over the cited 
references. Specifically, new claim 37 cites a can-attest message sent in an "unencrypted 
format" while new claim 38 cites that "each of the can-attest message and the attestation- 
wanted message is configured to preclude a) containing or b) using a cryptographic key." The 
cited references not only fail to disclose "can-attest" and "attestation-wanted" messages (as 
explained above) but also fail to teach or suggest that these messages are transmitted in an 
unencrypted format. 

Applicants have described these aspects in their original specification. An illustrative and 
non- limiting example of such a description is provided in Applicants' paragraph [0054], which 
explains how these two messages are "likely not of a sensitive nature." 

In direct contrast, attention is drawn to Yan's paragraph [0058] which teaches: "The 
process of dynamically establishing that a platform conforms to the specification expected by a 
remote party is done though a process called attestation. Attestation consists of several steps of 
cryptographic authentication . . ." and also to Yan's paragraph [0049] which teaches: "TSS 104 
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provides mechanisms for cryptosraphicallv reporting . . ." (response to local and remote 
challengers). 

Cited Art Made of Record 

The currently cited art made of record has been considered, but is not believed to affect 
the patentability of the presently pending claims. 
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CONCLUSION 

Applicants respectfully submit that all pending claims are allowable. Favorable 
reconsideration and allowance of the present application and all pending claims are hereby 
requested. If, in the opinion of the Examiner, a telephonic conference would expedite the 
examination of this matter, the Examiner is invited to call the undersigned representative. 



Date: October 21, 2009 /Joseph F. Oriti/ 

Joseph F. Oriti 
Registration No. 47,835 

Woodcock Washburn LLP 
Cira Centre 

2929 Arch Street, 12th Floor 
Philadelphia, PA 19104-2891 
Telephone: (215) 568-3100 
Facsimile: (215) 568-3439 
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